This invention relates to network communication, for example serial communication between devices using a protocol such as Transmission Control Protocol (TCP).
TCP has been employed for decades and has increased in popularity, or at least in usage, over the years. An advantage of TCP is its guaranteed delivery of error free data. Unfortunately, this guarantee comes with a price of greater complexity relative to some other network protocols. Such complexity can slow TCP communication, or at least make it difficult for TCP to be used as network data rates increase, for example from 100 MB/s ten years ago to 10 GB/s currently. Moreover, even for a 100 MB/s transmission line rate that was conventional ten years ago, TCP processing at the endpoints of the network proved a bottleneck that slowed network communication, as well as consumed inordinate CPU cycles.
A solution to the TCP bottleneck was provided by Alacritech, Inc., which offloaded established TCP connections from the host CPU to hardware that could process data transfer much more rapidly, significantly increasing TCP data transfer rates while reducing CPU utilization. Descriptions and claims to such a solution can be found in multiple patents, including U.S. Pat. Nos. 7,337,241; 7,284,070; 7,254,696; 7,237,036; 7,191,318; 7,191,241; 7,185,266; 7,174,393; 7,167,927; 7,167,926; 7,133,940; 7,124,205; 7,093,099; 7,089,326; 7,076,568; 7,042,898; 6,996,070; 6,965,941; 6,941,386; 6,938,092; 6,807,581; 6,757,746; 6,751,665; 6,697,868; 6,687,758; 6,658,480; 6,591,302; 6,470,415; 6,434,620; 6,427,173; 6,427,171; 6,393,487; 6,389,479; 6,334,153; 6,247,060; and 6,226,680, which are incorporated by reference herein. Also incorporated by reference is U.S. patent application Ser. No. 11/799,720, filed May 1, 2007.
For a situation in which an application is running on a host CPU while a TCP connection for that application is handled by a network interface card, however, certain communications between the host and the device could hamper performance. For example, some previous Alacritech host interface designs employed a command-response interface for sending data. That is, if an application performed a send, the host would encapsulate that send in a command. The address of that command was then written to the card, which would read out the command contents and send the data specified. When that data was fully acknowledged by the peer (the other side of the TCP connection), the card would notify the driver of the command completion by filling in a response buffer.
This interface worked well when performing large data transfers. For instance, if the application sent 64 KB of data, the driver would encapsulate it into a single command and hand it to the card. After all 64 KB of data was sent and acknowledged, the card would send a response to the host. As a result, 64 KB of data required only two interactions with the card—a dramatic reduction compared to traditional networking, which would have required sending 44 segments and processing ˜22 ACKs (assuming the default ACK-every-other-segment behavior of Windows®).
That command/response interface did not perform nearly so well, however, with small data transfers. For example, consider an application that is instead sending 64-byte sends asynchronously (meaning it doesn't wait for a previous send to complete before starting on the next one). In the previous model, the host would have constructed a command for each send, and received a response every time a send was acknowledged—a particularly high overhead for such a small amount of data. Although there were times when multiple sends could be coalesced into a single command, the inherent problem of relatively high overhead for small packet sends has remained.